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Abstract — Content-Centric Networking (CCN) is an 
emerging networking paradigm being considered as a 
possible replacement for the current IP-based host-centric 
Internet infrastructure. In CCN, named content becomes 
a first-class entity. CCN focuses on content distribution, 
which dominates current Internet traffic and is arguably 
not well served by IP. Named-Data Networking (NDN) 
is an example of CCN. NDN is also an active research 
project under the NSF Future Internet Architectures (FIA) 
program. FIA emphasizes security and privacy from the 
outset and by design. To be a viable Internet architecture, 
NDN must be resilient against current and emerging 
threats. 

This paper focuses on distributed denial-of-service 
(DDoS) attacks; in particular we address interest flooding, 
an attack that exploits key architectural features of NDN. 
We show that an adversary with limited resources can 
implement such attack, having a significant impact on 
network performance. We then introduce Poseidon: a 
framework for detecting and mitigating interest flooding 
attacks. Finally, we report on results of extensive simula- 
tions assessing proposed countermeasure. 

I. Introduction 

The Internet is an amazing success story, connecting 
hundreds of millions of users. The way people access and 
utilize it has changed radically since the 1970-s when 
its architecture was conceived. Today, the Internet has 
to accommodate new services, new usage models and 
new access technologies. Users are increasingly mobile, 
constantly accessing - and contributing to - remote 
information using a variety of devices such as laptops 
and smartphones. Ever-increasing mobility, device het- 
erogeneity, as well as massive amounts of user-generated 
content and social networking are exposing the limits of 
the current Internet architecture. 

To this end, there are some recent research efforts ll23l . 
ED, fl22l, O, (6| with the long-term goal of designing 

*Work done in part while at University of California, Irvine. 



and deploying a next-generation Internet architecture. 
One such new architecture is Named Data Networking 
(NDN). It is based on the principle of Content-Centric 
Networking, where content - rather than hosts - occu- 
pies the central role in the communication architecture. 
NDN is one of the five NSF-sponsored Future Internet 
Architectures (FIA) [IT); like the rest, it is an on- 
going research effort. NDN is primarily oriented towards 
efficient large-scale content distribution. Rather than 
establishing direct IP connections with a host serving 
content, NDN consumers directly request (i.e., express 
interest in) pieces of content by name; the network is 
in charge of finding the closest copy of the content, and 
of retrieving it as efficiently as possible. This decoupling 
of content and location allows NDN to efficiently imple- 
ment multicast, content replication and fault tolerance. 

One of the key goals of the NDN project is "security 
by design". In contrast to today's Internet, where security 
problems were (and are still being) identified along the 
way, the NSF FIA program (for all of its projects) 
stresses both awareness of issues and support for features 
and counter-measures from the outset. To this end, this 
paper investigates distributed denial of service (DDoS) 
attacks in NDN. 

DDoS attacks are considered to pose serious threats to 
the current Internet. They are generally performed using 
a large number of compromised hosts (zombies) that 
inject specially crafted IP packets in order to overwhelm 
their victims. The effectiveness of DDoS attacks is 
usually proportional to the number of zombies. NDN 
is not immune to them and might actually offer avenues 
for new DDoS attacks. 

In NDN, each content consumer's request (called an 
"interest") causes NDN routers to store a small amount 
of transient state. This state is flushed as the content is 
routed back to the consumer. This has been pointed out 
in previous work as a plausible attack vector - under the 
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name of interest flooding attack 11121 . However, there has 
been, thus far, no evidence whether interest flooding is 
even possible. In particular, to the best of our knowledge, 
there is no experimental work that estimates the amount 
of resources (i.e., bandwidth, number of compromised 
hosts available to the adversary, etc.) required to suc- 
cessfully carry out interest flooding attack. 

Roadmap and Contributions. Motivated by the im- 
portance of addressing security in the early stages of 
a potential new Internet architecture, we focus on DDoS 
over NDN, specifically, using interest flooding attack. We 
believe that interest flooding attack and countermeasures 
deserve an in-depth investigation before NDN can be 
considered ready for large-scale deployment. 

While some preliminary results of this research ap- 
peared in Q, in this paper we show, via extensive 
simulations, that interest flooding attacks are not just 
theoretical. It is, in fact, relatively easy to perform 
interest flooding with rather limited resources. In par- 
ticular, we simulate interest flooding over two realistic 
topologies Ifl4ll : the German research network DFN and 
the AT&T network. 

We then briefly discuss both proactive and reactive 
countermeasures. Next, we focus on reactive counter- 
measures and propose techniques for early detection of 
interest flooding. (This was left as an open problem 
in |[T2l .) We then describe the design and implementation 
of Poseidon - a framework for local and distributed 
interest flooding attack mitigation. Finally, we report on 
the effectiveness of proposed methods. 

Organization. We proceed with an overview of NDN 
in Section [TT] and discuss interest flooding and proposed 
countermeasures in Section [TTTJ Section [TV] details our 
simulation environment and Section [V] evaluates the 
impact of interest flooding attack in our setup. Section VI 
presents the Poseidon framework which is evaluated in 



Section VII Finally, Section VIII overviews related work 
and Section [FX] concludes the paper. 



II. NDN Overview 

NDN supports two types of messages: interests and 
content [3]. A content message includes a (human- 
readable) name, a payload and a digital signature com- 
puted by the content producer^ Names are composed 
of one or more components, which have a hierarchical 
structure. In NDN notation, "/" separates name compo- 
nents, e.g., /ndn/com/cnn/politics/f rontpage. 



Content is delivered to consumers only upon explicit 
request. Each request corresponds to an interest message. 
Unlike content, interests are not signed. An interest 
message includes a name of requested content^] In case 
of multiple content under a given name, optional control 
information can be carried within the interest to restrict 
desired content. Content signatures provide data origin 
authentication. However, trust and key management is 
the responsibility of each application. 

NDN routers forward interests towards the content 
producer responsible for the requested name, using name 
prefixes (instead of today's IP prefixes) for routing. For- 
warding Information Base (FIB) is a lookup table used to 
determine interfaces for forwarding incoming interests, 
and contains {name _prefix, interface] entries. Multiple 
entries with the same name _prefix are allowed, sup- 
porting multiple paths under which a given name _pref\x 
namespace is reachable. Each NDN router maintains a 
Pending Interest Table (PIT) - a lookup table containing 
outstanding [interest, arrival-interfaces] entries. 

When an NDN router receives an interest, it first looks 
up its PIT to determine whether another interest for 
the same name is currently outstanding. There are three 
possible outcomes: 

1) If the same name is already in the router's PIT and 
the arrival interface of the present interest is already 
in the set of arrival-interfaces of the corresponding 
PIT entry, the interest is discarded. 

2) If a PIT entry for the same name exists, yet the 
arrival interface is new, the router updates the PIT 
entry by adding a new interface to the set. The 
interest is not forwarded further. 

3) Otherwise, the router creates a new PIT entry and 
forwards the present interest using its FIB. 

Upon receipt of the interest, the producer injects content 
into the network, thus satisfying the interest. The re- 
quested content is then forwarded towards the consumer, 
traversing - in reverse - the path of the corresponding 
interest. Each router on the path flushes state (deletes 
the PIT entry) corresponding to the satisfied interest. In 
addition, each router may cache a copy of forwarded 
content in its local Content Store (CS). Large pieces 
of content are split into fragments with predictable 
names: e.g., fragment 5 of Alice's photo could be named 
It 1 i ckr/al ice /phot o-l . jpg/5. 

The above description of interest forwarding only ap- 
plies to content that has not been recently requested, i.e., 



'Content packets also carry additional fields that are not relevant 
to this paper and are therefore ignored. 



2 Or, a prefix of such a name - e.g. / cnn/politics is a prefix 
of /cnn/politics/f rontpage 
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not present in the CS of intervening routers. Whereas, a 
router that receives an interest for already-cached content 
does not forward the interest further; it simply returns 
cached content and retains no state about the interest. 

Not all interests result in content being returned. If an 
interest encounters either a router that cannot forward it 
further, or a content producer that has no such content, 
no error packets are generated. PIT entries for unsatisfied 
interests in intervening routers are removed after a prede- 
fined expiration time. The consumer (who also maintains 
its local PIT) can choose whether to regenerate the same 
interest after a timeout. 

III. Interest Flooding Attack and 

COUNTERMEASURES 

It is easy to see that an adversary can take advantage 
of CS and PIT - two features unique to NDN routers 
- to mount DoS/DDoS attacks specific to NDN. We 
focus on attacks that exploit the PIT, in particular, rapid 
generation of large numbers of interests that saturate the 
victim router's PIT. Once the PIT is completely full, 
all subsequent incoming (un-collapsible) interests are 
dropped. Flooding an NDN router with interests saturates 
its PIT if the rate of incoming interests is higher than the 
rate at which entries are removed from the PIT, either 
due to returning content or expiration. This is the goal 
of interest flooding attacks. 

There are several analogies between well-known SYN 
flooding |[3ll and interest flooding. In a SYN flooding 
attack, the adversary's goal is to consume resources on 
the victim host by initiating a large number of TCP 
connections. This requires the victim to keep state for 
each connection for a relatively long time. The main 
difference between SYN flooding and interest flooding 
attacks is the victim: the primary victims of interest 
flooding are routers. End-hosts are secondary victims. 

As observed in |[l2ll . there are at least three ways 
to mount this attack. The adversary can issue closely- 
spaced interests for: (1) existing static content; (2) 
dynamically-generated content; or (3) non-existent con- 
tent. In the rest of this paper, we refer to interests for 
non existing content as fake interests. 

In strategy (1), the adversary requests distinct content 
to avoid interest collapsing. If the flooding rate is suffi- 
ciently high, the producer (or, possibly, a router past the 
victim) will start dropping packets. This causes interests 
to linger in the victim's PIT until they expire, eventually 
filling up the victim's PIT. However, depending on the 
victim's ability to satisfy interests quickly (and flush 
them from the PIT), this strategy may be very expensive. 



Also, router caches might lower the impact of this attack, 
satisfying adversary's requests before they reach the 
victim. 

Strategy (2) is similar to (1), except that content is 
never returned from caches. Also, (2) may impose more 
load on the producer, due to the increased number of 
requests for content that can not be precomputed. This 
could cause higher round-trip latency and higher rate of 
dropped packets, which forces adversary's interests to 
remain in the victim's PIT longer. 

Strategy (3) allows the adversary to create entries 
in the victim's PIT for which no content will ever be 
returned. This has several consequences: 

• Adversarial interests referring to non-existenc con- 
tent are stored in the victim's PIT until they expire. 

• The maximum rate of adversarial interests does not 
depend on the bandwidth allocated by the victim 
to content packets, or on the adversary's ability to 
receive content. 

• Adversarial interests cannot be satisfied by router 
caches, since they request non-existing content. 

• If constructed properljj^] adversarial interests are 
never collapsed. 

These effects allow the adversary to efficiently fill up 
the victim router's PIT. which makes this attack more 
dangerous than (1) or (2). Therefore, in the rest of 
this paper, we focus on (3) - interest flooding via fake 
interests. 

It is straightforward to construct interests that are 
routed through the victim. Let R be the router advertising 
namespace /nsf/fia/. If the adversary issues interests 
for /nsf /fia/rrad (where "rnd" is a random string), 
they are forwarded through R. 

We now consider some possible interest flooding 
countermeasures and then propose a set of reactive 



techniques (called Poseidon) in Section VI 



A. Proactive Countermeasures 

Resource Allocation. Let mpu (maximum PIT usage) 
be the upper bound for the amount of PIT space required 
to route interests. We set mpu = rate ■ timeout, where 
rate is the sum of maximum rates of incoming interests 
on all interfaces, and timeout is the interest timeout 
value. If PIT size is at least mpu, it cannot be completely 
filled up. However, large and fast PITs are difficult 
and expensive to implement |[32l . Hence, if we assume 
that most content is returned before the corresponding 
interest expires, PIT size can be smaller than mpu. 

3 For example, a random component at the end of each name. 
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Alternatively, routers could set rate and timeout such 
that mpu matches PIT size. However, this would also 
reduce the amount of non-malicious traffic that a router 
can forward. 

Finally, a router could set a low timeout, such that 
fake interests are removed more promptly. Unfortunately, 
this would increase the likelihood of content (corre- 
sponding to expired PIT entry) being dropped, thus 
affecting network performance. 

Error Messages. NDN stipulates that whenever an in- 
terest cannot be satisfied, no error message is returned to 
the consumer. The NDN architecture could be amended 
to allow producers and routers to issue error messages 
when content cannot be returned. Such messages could 
be routed exactly like content, and flush PIT state of the 
routers they traverse. 

However, error messages have several drawbacks. 
There is a tradeoff between space and bandwidth usage: 
for each PIT entry removed by an error message, one 
extra packet - i.e., the error message itself - must be 
transported by the network. 

It is unclear whether error messages should be signed 
by the entity that issues them. If they are, signature 
generation costs might be high, thus punishing the pro- 
ducer. If they are not, they can themselves be used to 
implement attacks. Also, in case of multipath forwarding 
(i.e., multiple copies of the same interest concurrently 
forwarded to different interfaces), error messages may 
be handled differently with variable results. 

In the rest of the paper we focus on reactive counter- 
measures. 

B. Reactive Countermeasures 

We now discuss some reactive countermeasures, char- 
acterized by a detection and a reaction phase. Detection 
can be local or distributed. In the former, routers rely 
only on local metrics (e.g., PIT usage, rate of unsatisfied 
interests, amount of bandwidth used to forward content) 
to identify an attack. In the latter, nearby routers collab- 
orate to determine whether an attack is in progress and 
how to mitigate it. 

In case of successful interest flooding attack, the 
victim router can easily identify an attack by observing 
whether its PIT is full or whether the bandwidth allocated 
to forwarding of content is very small. However, it may 
not be possible for a router on the path to the victim 
to detect an attack in progress. Collaborative detection 
mechanisms allow routers to exchange information about 
their state, with the goal of detecting an attack in 
progress as soon - and as close to the adversary - as 



possible. Once an attack has been identified, routers 
must react to mitigate it. Ideally, routers should drop all 
interests from the adversary, while forwarding interests 
from regular users. Alternatively, routers could drop all 
interests corresponding to non-existent content. Clearly, 
routers can implement neither of these countermeasures: 
a smart adversary may be able to hide malicious traf- 
fic within legitimate data streams; additionally, routers 
cannot determine a-priori which interests will return 
content lfl2l . Feasible reaction strategies include: 

1. Identifying a (set of) namespace(s) under attack, 
and rate limit the corresponding interests. While 
this may not provide significant relief to the victim 
router, it could reduce the effects of the attack over 
other close-by routers. 

2. Identifying a set of interfaces to which the attack 
is directed, or from which it is coming, and rate- 
limit them. If fake interests are spread over many 
different namespaces but are concentrated over a 
limited set of interfaces, this approach may turn to 
be more effective. 

3. In addition to strategies 1. and 2., routers could 
identify PIT entries corresponding to (likely) fake 
interests and remove them before they time out. 

With collaborative detection, routers not only exchange 
information about the existence of an attack, but also the 
(locally detected) properties of such attack: strategies can 
take into account feedback from multiple routers. 

In this paper, we consider a particular collaborative 
approach - known as push-back lfT2l - to counter interest 
flooding. For each interface over which an attack has 
been detected, the router informs its neighbors. These 
routers might then react without waiting to detect the 
attack themselves. 

The amount of traffic generated by push-back mes- 
sages is negligible, in particular with respect to that 



of error messages overviewed in Section III-B In fact, 
when a router receives a push-back messages it does 
not forward it any further. Moreover, the number of 
unsatisfiable interests - and therefore the number of 
corresponding hypothetical error messages - is expected 
to be significantly higher than the number of push-back 
messages sent under normal conditions. 



Before presenting Poseidon (deferred to Section VI I, 
we introduce our evaluation environment for assessing 
feasibility of interest flooding attacks and the effective- 
ness of our countermeasures. 



5 



IV. Evaluation Environment 

We use simulations to quantify effects of both attacks 
and countermeasures. In particular, we run CCNx over 
NS-3 ifJSl via DCE. CCNx [2] is the official imple- 
mentation of NDN, originally developed by PARC, and 
released as open-source project in 2009. Even though 
CCNx codebase is still in early stage of development, 
it provides all basic functionalities of NDN. CCNx 
currently runs as an overlay on top of IP. Direct Code 
Execution |8] (DCE) is a framework developed by IN- 
RIA to allow regular applications to access a network 
environment simulated using NS-3. DCE allows us to 
test the latest CCNx, without reimplementing it for NS- 
3. 

We emphasize that running simulations of NDN as 
an overlay (over IP) reflects the status of the current 
CCNx implementation. In particular, even in the official 
NDN testbed [23], links between routers are essentially 
Generic Routing Encapsulation (GRE) tunnels carrying 
UDP packets. 

Experimental Setup. Our experiments are performed 
over two topologies shown in Figure [T] 

Figure |l(a)| corresponds to DFN - "Deutsches 



In particular, figures [2(a)] and [2(b)] show the total number 



ForschungsNetz" - the German Research Network ||9l , 
ifTOl . while Figure 1(b) corresponds to the AT&T net- 
work. 

We use the symbols Rx, Cx, Px, and Ax to repre- 
sent the x-th router, consumer, producer, and adversary- 
controlled node, respectively. Continuous lines in Figure 
[T] indicate connections between routers, dashed lines 
denote connections between consumers and routers, and 
dotted lines represent connections between producers 
and routers. In both topologies, we had 16 (honest) 
consumers and 2 producers. 

We first analyze the two topologies without any ad- 
versarial traffic. This provides us with a a baseline. 

Each consumer issues interests for content produced 
by P0 and PI. Interests retrieve distinct pieces of non- 
existent content; therefore, routers cannot collapse them 
or satisfy them via cached content. Consumers send a 
short burst of 30 interests, spaced by 2 ms, at time 
t = 1000 ms of the simulation. Starting from t = 
1200 ms, consumers switch to a rate of one interest every 
10.7 ms. In our configurations, such interest spacing 
allows routers to forward interests roughly at the same 
rate at which they receive content packets. We set 
routers' PIT size to 120 KB, while the interest expiration 
time was set to the default timeout of 4000 ms. 

We report the average of the various runs in Figure [2] 



of contents (y-axis) received by the different routers 
(x-axis), for the DFN and AT&T, respectively. Figures 



2(c) and 2(d) show PIT usage (y-axis) as a function 
of simulation time (x-axis) for the two topologies. The 



maximum value on the y-axis for figures 2(c) and 2(d) 
corresponds to the total space available in the PITs 
(120 KB). Also, the two vertical lines (at 1000 ms and 
26000 ms) indicate the instant when consumers start and 
stop sending interests. (The same notation is used in all 
graphs that refer to PIT usage reported in this paper.) 

V. Attack Effectiveness 

We assume that the adversary is able to corrupt a 
portion of the consumers, through which it implements 
the attack - i.e., issues fake interests. However the 
adversary is not allowed to control routers. We believe 
that this restriction is realistic and well represents the 
current scenario of DDoS attacks (e.g., Ifl6l0 . While we 
do not exclude that attacks might come from internal 
routers, we leave the investigation of this as future work. 

In our simulations we observe that successful instanti- 
ation of interest flooding requires very small amount of 
bandwidth. The adversary controls the nodes connected 
through a red solid line in Figure [T] The three adversarial 
nodes (AO, Al, A2) send interests for non-existent 
content for the namespace registered by P0 - i.e., all 
fake interests are routed to P0. Similar to honest nodes, 
the adversary starts sending interests at t = 1000 ms. 
Fake interests are generated every 1.337 ms. Behavior of 
honest consumers is unchanged from the base scenario. 

Attack results are plotted in Figure [3] for some repre- 
sentative nodes in both topologies. In particular, Figure 



3(a) and Figure 3(b) show the ratio of content packets 



forwarded during the attack with respect to the same 



network with no malicious traffic. Figures 3(c) and 3(d) 
show PIT usage. 



Figure 3(a) demonstrates that the attack has significant 
impact on the network. Several routers forward 20% 
of the original traffic. Similar behavior is evident from 



Figure 3(b) 



It is important to note that in both DFN and AT&T 
topologies, consumers are spread all over the network 
and the number of adversaries is quite small (three 
for both topologies). However, attack impact is signif- 
icant: fraction of packets forwarded by routers varies 
between 25% and 75% with respect to the base-line 
scenario. Differences in the effectiveness of the attack 
for different routers can be explained by their distance 
from the adversary-producer paths. We emphasize that 



(a) DFN topology 



(b) AT&T topology 
Fig. 1. Considered architectures: topologies 
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Fig. 2. Baseline behavior (no attack) 



reduced bandwidth available to consumers can only be for AT&T: R3 (closest to P0) is the first to succumb, as 



attributed to high PIT usage, as shown in Figure 3(c) 



and Figure 3(d) It is easy to see that the fraction of 
traffic forwarded by routers drops significantly once PITs 
fill up. As confirmed by Figure 3(a)| R9 is the first to 
reach its PIT limit, quickly followed by R2. This can 
be attributed to the central role R9 and R2 occupy in 
the DFN topology. Similar observations can be made 



shown in Figure 3(d) 

VI. Our Countermeasure: Poseidon 

We now introduce Poseidon, a framework for mitigat- 
ing Interest flooding. Poseidon is a set of algorithms that 
run on routers. Its goal is to identify traffic anomalies 
(especially, interest flooding) and mitigate their effects. 
Poseidon continuously monitors per-interface rates of 
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Fig. 3. Interest Flooding Attack (IFA): impact over baseline 



unsatisfied interests with respect to overall traffic. If 
these rates change significantly between two consecutive 
time intervals, it sets a filter on the offending interface(s) 
(which reduces the number of incoming interests). Addi- 
tionally, Poseidon can issue a push-back "alert" message 
to the same interfaces, to signal that an interest flooding 
attack is in progress. Upon receiving an alert message, 
it alters local detection thresholds. 

Poseidon keeps several statistics on expired interests. 
In particular, for each of them it records namespace 
and incoming/outgoing interfaces information. Relatively 
common network phenomenon (e.g., packet loss) and 
regular applications behavior usually account for only a 
(relatively) small amount of expiring interests in routers' 
PITs. In order to limit the number of false positive and 
minimize the reaction time, Poseidon monitors multiple 
metrics concurrently. 

In the next sections we introduce the detection and 
reaction phases of Poseidon. Notation used is shown in 
Table U 

A. Detection Phase 

Attacks are detected using two parameters: ui{rl,tk), 
and p{r\,tk)- The former represents the number of 



R 


set of all routers in the network running Poseidon 


Ti 


i-th router, 1 < i < |R| 


^ i 


j-th interface on router r 4 


tk 


fc-th time interval 




rate between incoming interest and outgoing content 
for a given interface r\ 




PIT space used by interests arrived on interface r\, 
measured at the end of interval tk 




interest flooding detection threshold for u}(rl,tjc) 


P(rJ) 


interest flooding detection threshold for p(r^,tfc) 



TABLE I 
Notation. 



incoming interests divided by the number of outgoing 
content packets, observed by a router on its interface 
r\ within time interval tk'- 

, a . (# of interests from r] at interval tk) 

w(ji,t k ) = — — —■ — . 

(# of content packets to r\ at interval tk) 

p(rj,tk) indicates the amount of space (in bytes) used 
to store interests in PIT, coming from interface r\ within 
time interval tk- 

Poseidon detects an attack when both uj(rj,tk) and 
p(rl,tk) exceed their respective thresholds and 
P(r^). The detection algorithm is executed at fixed time 



s 



intervals - typically every 60 ms - and in the presence of 
particular events, (i.e., push-back messages, as detailed 
below). 

The parameter u)(r?,t}.) is a good representation of 
the ability of routers to satisfy incoming interests in 
a particular time interval. (This is also confirmed by 



our experiments, detailed in Section VII ) In particular, 
w ( r i;*fc) > 1 indicates that the number of content 
packets forwarded to rj is smaller than the number of 
interests coming from the same interface. However, a 
small bursts of (either regular or non-satisfiable) interests 
may not be caused by an attack. Hence, taking into 
account only ujM,^) (i.e., not considering p(r~-,tk)) 
may cause the detection algorithm to report a significant 
number of false positives. Applying countermeasures 
may, in this case, produce negative effects to the overall 
network performance. 

We argue that neither increasing O(r^), nor computing 
uj(rl,tk) over longer intervals, produces the indented 
effects. In fact, in the first case the bound must be set 
high enough to avoid classification of short burst of 
interests as attacks; however this could inevitably lead 
to late- or mis-detection of actual attacks. Increasing 
the size of the interval over which f2(r|) is computed 
may reduce the sensitivity of Poseidon to short burst 
of interests. An interval length similar or longer than 
the average round-trip time of interest/content packet, 
in fact, may allow (part of) the content requested by the 
burst to be forwarded back, reducing a;(rf to a value 
closer to 1 . However this could significantly increase the 
detection time. 

Instead, to improve detection accuracy (distinguish- 
ing naturally occurring burst of interests from attacks), 
Poseidon takes into account also p(r?,ifc). This value 
measures the PIT space used by interests coming from 
a particular interface. This allows Poseidon to maintain 
the number of false positives low - when compared to 
considering solely Lo(rj,tk) - while allowing it to detect 
low-rate interest flooding. In a low-rate interest flooding 
attack the adversary limits the rate of fake interests 
to keep o;(r|,tjt) below its thresholds. Monitoring the 
content of the PIT allows Poseidon to observe the effects 
of the attack, rather than just its causes, allowing for 
early detection. 

To sum up, different parameters monitored by Po- 
seidon act as weights and counterweights for interest 
flooding detection. When a router is unable to satisfy 
incoming interests over a relatively short period, p{r\ , t^) 
may exceed the detection threshold but oj{r 3 -,t} t ) will 
not; when the router receives a short bursts of interests, 



u(rj,tk) may become larger than fi(r^) but the PIT 
usage will likely be within normal values. To stay unde- 
tected, an adversary willing to perform interest flooding 
must therefore: (1) reduce the rate at which it sends 
interests, which limits the effects of the attack; and/or 
(2) restrict the attack to short burst, which makes the 
attack ineffective. 

Thresholds O(r^) and P(r|) are not constant and may 
change over time to accommodate different conditions 
of the network. As an example, push-back messages 
described below provide input for determining more 
appropriate values for these thresholds. 

B. Reaction Phase 

Once an interest flooding attack from interface r\ of 
router r» has been identified, Poseidon limits the rate of 
incoming interests from that interface. The original rate 
is restored once all detection parameters fall again below 
their corresponding thresholds. 

When collaborative (distributed) countermeasures are 
in place, once a router detects adversarial traffic from 
a set of interfaces it limits their rate and issues an 
alert message on each of them. An alert message is an 
unsolicited content packet which belongs to a reserved 
namespace ("/pushback/alerts/" in our implemen- 
tation), used to convey information about interest flood- 
ing attack in progress. 

There are two reasons for using content packets rather 
than interests for carrying push-back information: (1) 
during an attack, the PIT of the next hop connected 
to the offending interface may be full, and therefore 
the alert message may be discarded; and (2) content 
packets are signed, while interests are not - this allows 
routers receiving alert messages to determine whether 
the information they carry is legitimate. 

Routers running Poseidon do not process alert mes- 
sages as regular content: alerts are not checked against 
PIT content and are not forwarded any further. The 
pay load of an alert packet contains: the timestamp corre- 
sponding to the alert generation time; the new (reduced) 
rate at which offending interests will be accepted on 
the incoming interface; and detailed information about 
the attack - such as the namespace(s) used in malicious 
interests. 

Router r.j receiving a packet msg processes it as 
detailed in Algorithm [T] A persistent interest flooding 
attack on router rj causes it to send multiple alert mes- 
sages towards the source(s) of the attack. Such sources 
will decrease their thresholds and P(r|) until 

they detect the attack and implement rate-limiting on 
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the malicious interests. If no attack is reported for a 
predefined amount of time, thresholds are restored to 
their original values. 

This push-back mechanism allows routers that are not 
the target of the attack, but are unwittingly forwarding 
malicious interests, to detect interest flooding early. In 
particular, alert messages allow routers to detect interest 
flooding even when they are far away from the intended 
victim - i.e., close to nodes controlled by the adversary, 
where countermeasures are most effective. 

Algorithm 1: Message Processing 

input : Incoming packet msg from r\ ; waitjtime 
fi(r^); P(r^); Scaling factor s; 
Alert message m from interface r\ 
if msg is ContentObject then 
process msg as ContentObject 
return 
end if 

if msg is AlertMessage then 

if Verify '(msg. signature) and IsFresh (msg) and 
time from last Alert received from r\ > wait_time then 
/ / Push-back reaction 
Decrease (fi(r^), s) 
Decrease (P(r^), s) 
else 

drop msg 
return 
end if 
end if 

if msg is Interest then 

if u>(ri,t k ) > Sl(ri) and p(r{,t k ) > P(rf) then 
drop msg 

if time from last Alert sent on interface r\ > waitjime 
then 

// Push-back alert message generation 
send Alert to r\ 
end if 
else 

process msg as Interest 
end if 



The Decrease function divides the threshold in input 
by s at each invocation. Similarly, the Increase function 
increases its input by 1/8 of the current value. Consumers 
request the same content at the same rate as in the 
previous simulations. Similarly, the nodes controlled 
by the adversary implement interest flooding as in the 
simulation in Section [Vj 

Local Countermeasures. Figure |4] shows the result of 
applying local countermeasures. Values shown represent 



the average of 20 executions. Figure 7(a) and Figure 



7(b) report the ratio of content packets received with 
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respect to the scenario with no adversary. (For com- 
parison purposes, in the same figure we also report the 
corresponding value with no countermeasures in place.) 

Our results show that the rate-based (local) counter- 
measure - while simple - is very effective. In particular, 
the countermeasure is very effective in the DFN topology 



(Figure 7(a) I. Most routers, in fact, forward virtually the 
same amount of content they otherwise forward without 
attack - up from about 60% with no countermeasures. 
Moreover, with Poseidon no router forwarded less than 
80% of the original traffic in our experiments. Unfortu- 
nately, For the AT&T network, while the countermeasure 



can still mitigate the effect of the attack (see Figure 7(b) I, 
unfortunately its benefit is not as good as observed for 
the DFN network. 



Figures 4(a) and 4(b) report PIT usage over the same 



experiments. Figure 4(a) presents our results for the DFN 
architecture. For clarity, we do not report measurements 
for nodes R4, R29, R22, R25, R20, R14 - almost 
identical to those of R18. Results for routers R3, R5, R6, 
R7, R8, Rll, R12, R15, R17, R19, R26, and R28 are 
also not reported being very similar to those of R13, R21, 
and R23. Similarly, some routers of the AT&T network 



25: end if 



are not represented in Figure 4(b) 



VII. Evaluation 
In this section we report on experimental evaluation 



of countermeasures presented in Section VI Our coun- 
termeasures are tested over the same topologies used 
in previous experiments and detailed in Figure [T] Each 
router implements detection techniques discussed in Sec- 
tion IVI-AI and countermeasures from Section IVI-BI 

As for the parameters used in our experiments, we 
considered these initial values: for each router r^, in- 
terface rj, O(r^) = 3 and P(r|) = 1/8 of the PIT size. 
Furthermore, we set scaling factor s = 2 and wait_time 
(both used in Algorithm [TJ to 60 ms. 



Our results also show that this countermeasure signifi- 
cantly reduces the PIT usage in presence of an adversary. 
The effects of the rate-based approach are evident at 
t = 6000 ms, when fake interests corresponding to the 
initial phase of the attack - those that triggered the 
detection - expire. This shows that the detection time 
for the attack is around one second. 



Distributed Countermeasures. Figures |7(a)| and |7(b) 
show the ratio of content packets received under at- 
tack with the the push-back countermeasure in place. 
To simplify comparison, we report the results of the 
simulations of the attack without countermeasures and 
with the previous (local) countermeasure. 

Both architecture exhibits an interesting behavior: the 
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push-back mechanism offers visibly better performance 
compared to the rate-based countermeasure. In partic- 
ular, for the DFN architecture, R28, R20, R29, and 
R25 forward 16%, 13%, 11%, and 8% more content 
packets than in their counterparts in using the rate-based 
countermeasure. The impact is far more important for 
the AT&T network: for several routers the improvement 
with respect to the local countermeasure is more than 
300%. 

A similar conclusion applies also to the PIT usage - 
which is another measure for attach effectiveness. In fact, 
for the DFN it is possible to observe a significant benefits 
of push-back comparing Figure 4(a)| to Figure 6(a) 



in 



particular for the PIT of router R27. Similarly, for the 
AT&T it is possible to observe a significant benefits of 



push-back comparing Figure 4(b) to Figure 6(b) e.g. for 
the PIT of router R31. 

So far we have considered cumulative results for 
throughput; however, it is interesting to analyze also 
how the content packets throughput varies over time in 
different scenarios. Figures [8] and [9] show the effect of 
our rate-based countermeasure on some routers, which 
we deem notable in our topologies. This figures clearly 
illustrate that using the local (rate-based) countermeasure 
routers are able to provide roughly the same throughput 
measured without interest flooding. We obtained analo- 
gous results (not shown with graphs) for the push-back 
countermeasure. 

An interesting phenomenon highlighted by Figures 



8(b) and 9(b) is the cyclical behavior of the amount 
of bandwidth available to content. This pattern can be 



explained as follows. As soon as the PITs of these routers 
are rilled up with fake interests, no legitimate interests 
are forwarded and therefore no content is routed back. 
After four seconds - i.e., in our setting, the lifetime of 
an unsatisfied interest - fake interests are removed from 
the PITs allowing routers to forward new (legitimate) 
requests for content. When this happens, the adversary is 
quickly able to fill up PITs again. This process continues 
indefinitely for the whole duration of the attack. 
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VIII. Related Work 

NDN is an instantiation of the Content-Centric 
Networking (CCN) paradigm (an alternative term 
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"Information-Centric Networking" is largely synony- 
mous). Other related architectures include the Data- 
Oriented Network Architecture (DONA) [QjJ] and 
TRIAD. 

DONA is based on "flat" self-certifying names, com- 
puted as the cryptographic hash of the producer's public 
key and a (possibly) human-readable label. New content 
is published - i.e., registered - with a tree of trusted 
resolution handlers to enable retrieval. Resolution han- 
dlers maintain a forwarding table that provides next-hop 
information for pieces of content in the network. As 
such, DONA does not support dynamically generated 
content. 

Similar to NDN, TRIAD Q names content using 
human-readable, location-independent names. It maps 
names to available replicas of data using an integrated 
directory. It then forwards requests until a copy of the 
data is found. The data location is returned to the client, 
who retrieves it using standard HTTP/TCR TRIAD relies 
on trusted directories to authenticate content lookups (but 
not content itself). For additional security, the authors 
of J51 recommend to limit the network to mutually 
trusting content routers. 

There is lots of previous work on DoS/DDoS at- 
tacks on the current Internet infrastructure. Current lit- 
erature addresses both attacks and countermeasures on 
the routing infrastructure iPTBI . packet flooding [18], 
reflection attacks ||26*1| . DNS cache poisoning [27] and 
SYN flooding attacks ED- Proposed counter-measures 
are based on various strategies and heuristics, including: 
anomaly detection (TJ, ingress/egress filtering [30], IP 
trace back ED, lEH, ISP collaborative defenses H and 
user-collaborative defenses |fT3l . 

The authors of lTT2l present a spectrum of possible 



DoS and DDoS attacks in NDN. They classify those 
attacks in interest flooding and content/cache poisoning, 
and provide a high-level overview of possible counter- 
measures. However, the paper does not analyze specific 
attacks or evaluate countermeasures. 

NDN caching performance optimization has been 
recently investigated with respect to various metrics 
including energy impact ifTTI . ll28l . EDI . To the best of 
our knowledge, the work of Xie, et al. [34] is the first to 
address cache robustness in NDN. This work introduces 
CacheShield, a mechanism that helps routers to prevent 
caching unpopular content and therefore maximizing the 
use of cache for popular one. 

IX. Conclusion 

In this paper we discussed interest flooding-based 
DDoS over NDN. We provided, to the best of our knowl- 
edge, the first experimental evaluation of the attack. Our 
experiments are based on the official NDN implementa- 
tion codebase; we argue that this setup provides reliable 
results, and closely mimics the behavior of physical 
(non-simulated) networks. 

We demonstrated that interest flooding attack is a 
realistic threat; in particular, we showed that an adver- 
sary with limited resources can reduce the amount of 
bandwidth allocated for content objects to 15-25% of 
the total bandwidth. 

We then introduced Poseidon, a new mechanism for 
detecting and mitigating interest flooding. We showed 
that the benefits of Poseidon are significant: in fact, 
routers running our countermeasure are able to use 
always more than 80% (and often more than 95%) of the 
available bandwidth during the attack. Poseidon relies on 
both local metrics and collaborative techniques for early 
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detection of interest flooding. Reaction to the attack is 
coordinated between adjacent routers. 

Our experiments suggest that in large complex net- 
works collaborative countermeasure provide better re- 
sults, while in simple topologies local countermeasures 
are to be preferred. 
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